zimg
zimg copied to clipboard
A lightweight and high performance image storage and processing system.
你好,昨天我编译通过了这个程序,感谢你共享了这么好的程序,所以决定使用在项目中,但我们还是有一些需求有点不一样,下边是我不成熟的想法,想交流一下 1 我们的项目最开始需求是需要一个图片服务器来负载微信,APP,网站的请求上所带的图片。但是现在客户需求不仅仅是图片还有各种文档。我的想法是无论是保存图片或者文档,这个动作应该是一样的。只不过在取图片的时候,图片操作有imagemagick的操作来支持,是不是各种文档在存储中只需要注意分片存储就行了? 2 在[zhttpd.c] post_request_cb,在接受数据的时候用了一个临时的buffer,请问这个buffer能不能用数据节点队列管理起来,因为根据我的经验在socket通信的时候,接受数据这部分是很耗时的,因为缓冲区会很大,接收的数据是文件级别的 3 对于链接内存数据库的链接是不是应该发送心跳包保持链接,或者参照java提供的客户端提供出来一个pool来,这方面我写过很多池,我尝试着写一下
mkdir -p build/zimg cd build/zimg; cmake /src; make -j 4; cp zimg /bin CMake Error: The source directory "/src" does not exist. Specify --help for usage, or press the help...
按照官方给出的官方文档来安装,源码编译安装,从来没成功过。make的时候,报错 [](url)
`CMakeFiles/zimg.dir/zscale.c.o: In function `convert': zscale.c:(.text+0x2f): undefined reference to `MagickAutoOrientImage' collect2: error: ld returned 1 exit status make[3]: *** [zimg] Error 1 make[3]: Leaving directory `/root/zimg/build/zimg' make[2]: *** [CMakeFiles/zimg.dir/all] Error 2...
As far as I've seen images are deleted by a GET-Request to `/admin?md5=12345&t=1`. Best practice IMHO would be to * Never be destructive on GET requests. * Use DELETE requests...
服务器之前已经安装了ImageMagick7.0.1,在编译的时候提示`MagickWriteImageBlob`,`MagickGetImageSize`这两个函数已废弃,导致编译失败。 google了一下,`MagickWriteImageBlob`替换为`MagickGetImageBlob`;`MagickGetImageSize`, 需要改为`GetBlobSize(wand->images)`的方式 比如 `zhttpd.c`中的339行: ``` MagickSizeType size = MagickGetImageSize(im); /*替换为*/ Image *image = GetImageFromMagickWand(im); MagickSizeType size = GetBlobSize(image); ``` 影响的文件有 `zdb.c`,`zhttpdd.c`,`zimg.c`
在zhttpd.c:781行左右,获取Content-Length的长度,分配buffer,读取POST的数据。 但实际上,chunked数据传输时,Content-Length并不是有效的。 如果存在导致缓冲区溢出崩溃。 ` while((evblen = evbuffer_get_length(buf)) > 0) //获取的是Content-Length的长度 { LOG_PRINT(LOG_DEBUG, "evblen = %d", evblen); rmblen = evbuffer_remove(buf, buff, evblen); //实际chunked的数据 LOG_PRINT(LOG_DEBUG, "rmblen = %d", rmblen); if(rmblen < 0)...
``` 2015/08/20 11:41:32:341980 [DEBUG] Binary Cache Find Key[9eaa0e325d1b498272799262e9f3c649:0:0:1:0:-1:-1:0:75:none], Len: 43554. 2015/08/20 11:41:32:342012 [DEBUG] Hit Cache[Key: 9eaa0e325d1b498272799262e9f3c649:0:0:1:0:-1:-1:0:75:none]. 2015/08/20 11:41:32:342040 [DEBUG] Begin to Caculate MD5... 2015/08/20 11:41:32:342200 [DEBUG] md5: aabc4a31d3301285dc44c5c62a1cb207 2015/08/20 11:41:32:342240...